RAG 核心知识点全集

第一部分：基础认知

这一部分回答"是什么"和"整体长什么样"——建立对 RAG 的全局认知。

1. RAG 是什么？为什么需要 RAG？

"为什么不让 LLM 直接回答，为什么要用 RAG？"

LLM 的三大知识缺陷

1. 知识截止：训练数据有截止日期，使用的是过去的数据，新发生的事情（昨天发生的事）它不知道
2. 私有数据无法触达：公司的内部文档、客户数据、业务逻辑，这些 LLM 从来没见过
3. 容易幻觉：当 LLM 不确定但又想回答时，它会编造看似合理但完全错误的信息。这个问题没有外部知识验证时尤其严重

RAG 的核心思路

RAG（Retrieval-Augmented Generation，检索增强生成）其本质就是：在 LLM 生成回答之前，先从外部知识库中检索相关信息，把检索结果塞进 prompt，让 LLM 基于事实回答。

核心点：RAG 不是替代 LLM，是给 LLM 补充外部知识。LLM 负责理解和生成，RAG 负责提供事实依据。

2. RAG 的完整链路是怎么样的？

整体分为离线预处理阶段 + 在线推理问答阶段两大块：

【离线构建】
原始文档 → 清洗 → 文本分块Chunk → Embedding向量化 → 存入向量数据库

【在线问答】
用户提问Query → Query向量化 → 向量库相似度检索 → Rerank重排(可选) → 拼接上下文Prompt → LLM生成回答

离线阶段每一步做什么：

步骤	做什么	关键决策
1. 数据源接入	读取 PDF、Word、网页、数据库等原始文档，统一提取纯文本	支持哪些文件格式？是否需要对接业务系统/API？是否增量同步？
2. 文本清洗与预处理	过滤乱码、水印、重复段落、页眉页脚；规整格式、表格转文本、图片 OCR	清洗粒度到什么程度？表格/公式/图片如何处理？是否保留原始排版结构？
3. 文本分块（Chunk 切片）	按固定长度/滑动窗口/语义边界将长文本切成短文本块	Chunk 大小设多少（512/1024 token）？重叠率 overlap 多少？用固定切分还是语义切分？
4. 向量化（Embedding）	调用 Embedding 模型将每个 Chunk 转为高密度数值向量	选哪个 Embedding 模型（bge/M3E/text-embedding）？向量维度多少？是否需要多语言支持？
5. 向量入库	将 Chunk 文本、向量、元数据存入向量数据库并建立索引	选哪个向量库（FAISS/Milvus/Chroma/Qdrant）？索引类型选什么？元数据字段怎么设计？

在线阶段每一步做什么：

步骤	做什么	关键决策
1. Query 向量化	用户输入问题，用同一 Embedding 模型转换为查询向量	是否需要对 Query 做改写/扩写/多轮改写？是否用大模型先拆分多子问题再检索？
2. 向量相似度检索	在向量库中做相似度匹配，召回 Top-N 最相似的文本 Chunk	Top-K 召回多少条？相似度阈值设多少？是否叠加元数据过滤？是否用混合检索（向量 + 关键词 BM25）？
3. 重排（Rerank，可选）	用重排模型对召回结果重新打分排序，筛掉无关内容	是否启用 Rerank？选哪个重排模型（bge-reranker/cross-encoder）？重排后保留几条？
4. 构造 Prompt 上下文	将系统指令、参考文档、用户问题拼接成完整 Prompt	系统提示词怎么写（是否要求引用来源、禁止编造）？上下文塞入多少 token？是否先对检索结果做摘要压缩？
5. LLM 生成回答	大模型基于参考资料生成答案，后处理后返回用户	选哪个生成模型？温度 temperature 设多少？是否做答案校验/幻觉检测？是否返回引用来源链接？

---

第二部分：核心技术原理

有了全局认知后，接下来深入理解 RAG 的底层核心：向量是怎么来的、怎么选模型、怎么存。

3. 向量检索的原理是什么？

"向量检索和关键词检索有什么区别？"、"Embedding 的原理是什么？为什么语义相似的文本向量距离近？"

一句话总结

把文本变成高维空间中的点，语义越近，距离越近。检索 = 找离问题向量最近的文档向量。

举个例子：

"如何优化数据库查询" → [0.12, -0.34, 0.56, ...]  ← 这些向量在空间中距离很近
"数据库性能调优方法" → [0.11, -0.32, 0.55, ...]
"今天天气不错"       → [-0.45, 0.78, -0.23, ...]  ← 和上面距离远

向量检索 VS 关键词检索

对比维度	关键词检索（BM25/TF-IDF）	向量检索（Embedding + ANN）
匹配方式	字面匹配（词是否出现）	语义匹配（意思是否相近）
能否理解同义词	❌ "苹果"和"iPhone"搜不到一起	✅ 语义相近的都能召回
对拼写错误的容忍度	低（"资料库"搜不到"数据库"）	高（Embedding 有容错能力）
排序依据	词频、逆文档频率	向量距离（余弦相似度）
典型场景	精确查找、标题搜索	语义召回、问答、推荐

本质区别： 关键词检索是在"词"上做集合运算；向量检索是在"语义空间"中做距离度量。

关键词检索： 文档 → 分词 → 倒排索引 → 词匹配 → 排序
向量检索：   文档 → Embedding → 向量库 → ANN → 距离排序

语义空间视角：
                 [如何优化数据库查询] ●
                         ↙
                 [数据库性能调优] ●

    [今天天气不错] ● ← 离得很远

Embedding 原理 —— 语义相近的向量为什么近？

把文本转换成固定长度的浮点数数组（向量），本质是把高维语义压缩到低维空间。

训练过程（以 BERT 为例）：

1. 遮住句子中的一个词，让模型预测 → 模型必须理解上下文
2. 训练数据里"苹果"和"iPhone"经常出现在相似上下文中（"今天买了__"）
3. 模型把这种共现关系编码成向量，语义相近的词在向量空间中位置接近
4. 一句话的向量 = 各 token 向量的汇聚（池化或 CLS 位置）

直觉理解： 两个词如果经常出现在相同的"朋友圈"（上下文），它们就被拉到相近的位置。

黄金三问

Q1：向量检索和关键词检索有什么区别？

关键词检索是字面匹配（词是否出现），向量检索是语义匹配（意思是否相近）。关键词检索无法处理同义词、拼写误差；向量检索能理解语义，但对长尾词可能不如关键词精确。

Q2：Embedding 的原理是什么？

通过大规模语料训练（如 BERT 的 MLM 任务），让模型学习词的共现模式。经常出现在相似上下文的词，被映射到向量空间中相近的位置。

Q3：为什么语义相似的文本向量距离近？

训练目标决定了向量空间的结构：相似上下文的词 → 向量被拉近 → 句向量由词向量汇聚而成 → 语义相近的句子自然聚在一起。

4. Embedding 模型怎么选？

理解了 Embedding 原理之后，下一个实际问题是：用哪个模型？

选型维度

语言支持、向量维度、检索效果（MTEB 排名）

中文场景主流模型

模型	维度	特点
bge-large-zh-v1.5	1024	中文效果最好，开源，本地部署
bge-m3	1024	多语言，支持稠密+稀疏+多向量三种检索
text-embedding-3-large (OpenAI)	3072	效果好，但 API 调用有成本，中文不如 bge
text-embedding-3-small (OpenAI)	1536	便宜，效果够用，英文场景首选

维度越高越好吗？

维度高只能说明其精细度高、表达能力强，但是存储和检索的成本会相应提升。

5. 向量数据库怎么选？Milvus、FAISS、Qdrant 各自适合什么场景？

模型产出向量后，需要一个地方存起来并高效检索——这就是向量数据库的职责。

三者对比

	FAISS	Milvus	Qdrant
类型	库（Library）	数据库（Database）	数据库（Database）
部署方式	嵌入应用进程	独立服务，支持分布式	独立服务，轻量级
持久化	需自己实现	原生支持	原生支持
适合规模	百万级以下	亿级	千万级
运维成本	低（无额外服务）	中（需部署集群）	低（单节点起步）
生产环境	适合原型验证	适合大规模生产	适合中小规模生产

选型理由，如：选 Milvus，因为生产环境需要多副本部署和持久化，FAISS 不支持分布式，Qdrant 当时生态不够成熟，Milvus 生态成熟。

---

第三部分：检索策略

有了向量库和 Embedding 模型，接下来决定怎么切文档、怎么检索、怎么精排——这是 RAG 效果的"发动机"。

6. Chunk 怎么切？切大了切小了各有什么问题？

在把文档扔进向量库之前，首先得决定怎么切。Chunk 策略直接影响检索质量。

切大切小了会有什么问题

• 切大：信息稀疏 —— 一个 chunk 中内容过多，在检索时无关内容可能会将真正相关的内容淹没
• 切小：上下文丢失 —— 一段逻辑连贯的内容被切开，检索出来的内容将可能出现信息缺失，倒逼模型编造内容

三种主流切分方式

1. 固定长度切分：优点是简单，缺点是可能会将完整的一句话切开
2. 递归切分：按段落→句子→字符的优先级（文章结构）递归切分
3. 语义切分：用 Embedding 计算相邻句子的语义相似度，在语义断点处切分。效果最好，但计算量大

处理不同类型的文档

文档类型	处理策略
Markdown	按标题层级切分，保留标题层级信息
PDF	先解析表格和图片，再按段落切分
代码	按函数/类切分，保留完整代码块
FAQ	每个问答对作为一个 chunk，不要拆开

7. 混合检索：向量 + 关键词

Chunk 切好入库后，到了在线检索环节。纯向量检索虽然语义理解强，但存在明显短板，生产环境通常引入关键词检索组成混合方案。

纯向量检索的三个致命问题

1. 精确匹配不行：比如用户查规范号 RFC 7231，向量只会识别"HTTP 相关文档"，返回一堆泛化内容，找不到原文里明确写了 RFC 7231 的资料
2. 专业术语召回差：像 HPA、GPU、LLaMA 这类行业缩写，口语化描述和缩写的向量差距很大。搜"HPA 配置"，向量只会匹配"k8s 自动扩缩容"，真正带 HPA 实操步骤的文档反而排不到前面
3. 专有名词易遗漏：公司内部产品名、项目代号、特定人名，属于独有的关键词，语义模型很难区分，纯向量极易漏掉包含该名词的关键文档

简单总结：向量擅长懂意思，但不擅长找文字。

什么是混合检索？为什么能解决问题？

混合检索 = 两路并行检索（稠密向量检索 + 稀疏关键词检索「BM25」），再融合两路结果打分排序，互相弥补短板：

1. 向量检索负责抓语义：同义词、近义词、不同表述但含义一致的内容都能召回。如"SQL 调优"能匹配"数据库性能优化"
2. 关键词检索负责抓精准文字：严格匹配输入中的专有名词、编号、缩写、专业术语，只要文档包含关键词就会高分召回

RRF 倒数排名融合（Reciprocal Rank Fusion）

向量检索和 BM25 检索会各自返回一份有序文档列表，两套排名标准不一样，不能简单直接拼接。RRF 解决了这个融合问题。

RRF 的优势：

1. 无需归一化两路检索的相似度分数，向量余弦分和 BM25 分值区间完全不统一，RRF 不受影响
2. 实现简单、无复杂调参，仅一个超参 k
3. 兼顾两路优势：同时在向量、关键词检索排名高的文档最终权重最高，既语义相关又包含精准关键词
4. 抑制单一路噪声：仅在某一路靠前、另一路完全无匹配的文档总分会被压低，过滤无效结果

# RRF_score(d) = Σ 1 / (k + rank_i(d))
def rrf_merge(vector_results, bm25_results, k=60):
    scores = {}
    for rank, doc in enumerate(vector_results):
        scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1)
    for rank, doc in enumerate(bm25_results):
        scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1)
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)

混合检索权重应该怎么调？

除了 RRF 排名融合，还有另一种思路——手动设权重。两种常见做法：

1. 手动调权重：向量 0.7 + BM25 0.3，在验证集上试出最佳比例
2. RRF 合并：不设权重，靠排名融合，更稳健

生产环境推荐 RRF，因为不同 query 的最佳权重差异很大，固定权重不一定好。

纯向量检索只依赖语义相似度，面对规范编号、专业缩写、内部产品名时精准召回能力弱，容易漏掉关键文档；单独 BM25 只能做字面匹配，无法识别同义改写，语义相关文档召回不足。混合检索两路并行，向量负责语义泛化匹配，BM25 负责精准关键词命中，再用 RRF 算法融合，兼顾语义相关性与关键词精准度，大幅提升检索准确率。

8. Rerank 重排序 & Top-K 取值

混合检索粗筛出一批候选后，还需要更精细的排序——这就是 Rerank。

"为什么已经做了向量 + 关键词检索，还要额外加 Rerank？"

检索 VS Rerank 核心定位区别

1. 检索（混合检索：向量+关键词）= 粗筛

   • 目标：从几十万、百万级知识库中快速过滤，找出一批候选文档
   • 特点：速度极快，但是相关性打分只是近似值，判断精度有限

2. Rerank 重排序 = 精排

   • 目标：只对粗筛出来的少量候选文档，重新精细打分，调整顺序，把真正贴合问题的内容置顶
   • 特点：计算成本高、速度慢，但相关性判断极度精准

为什么混合检索打分依然不准？底层模型差异

1. 检索底层：Bi-Encoder 双塔模型（向量 Embedding 模型）

   • 流程：Query、文档 Chunk 分开独立编码，互相看不到对方内容，生成两个独立向量，最后只靠余弦相似度判断相关度
   • 缺陷：无法细粒度对比问句和文档之间的细节匹配关系，只能判断整体语义近似，容易出现"看似相关、实则答非所问"的噪声文档

2. Rerank 底层：Cross-Encoder 交叉编码器

   • 流程：将「用户问题 + 单条文档」拼接成一条输入，同时送入模型，模型完整对比两者所有字词、逻辑细节，输出精准相关性分数
   • 优势：能识别细微差异，过滤掉语义相近但无关的文档
   • 短板：无法提前预计算向量，每条问答对都要单独推理，计算开销大，不能用于全库检索，只能少量候选精排

Rerank 实际收益量化对比

评估指标	仅混合检索（无 Rerank）	增加 Rerank 重排后
Top5 召回率	71%	89%
Top3 准确率	65%	84%

工业常用开源/商用 Rerank 模型

模型名称	适用场景特点
bge-reranker-v2-m3	中文场景效果最优，开源可本地部署
bce-reranker-base_v1	轻量小模型，推理速度快，中文友好
Cohere Rerank	闭源 API 服务，英文效果顶尖

Top-K 设多少？设大了设小了各有什么问题？

Rerank 流程中，检索阶段的 Top-K 和精排后的 Top-K 是两个关键参数：

• 设小了（K=3）：可能漏掉相关文档，召回不够
• 设大了（K=20）：太多无关信息干扰 LLM，增加幻觉风险和 Token 消耗

通常 K=5-10 是比较好的平衡点。加了 Rerank 之后的标准流程是：先用 K=20 检索粗筛 → Rerank 精排 → 取 Top-5 送入 LLM。

混合检索只是粗筛，只为了能快速从海量文档中捞出一批候选，但它依靠 Bi-Encoder 双塔向量打分（问句和文档分开编码），没办法精细对比细节，容易混入看似语义相近但与实际无关的内容。而 Rerank 使用 Cross-Encoder 交叉编码器，把问题和文档拼接在一起同步输入模型，细粒度判断真实相关性，打分精度更高。但 Cross-Encoder 的推理速度慢，全库遍历耗时高。所以生产环境标准流程是：先用混合检索粗筛出 Top20，再通过 Rerank 精排，最终取最相关的 Top3~Top5 送入 LLM。

「一句话总结」：检索粗筛快而粗，Rerank 精排慢而准；双塔负责海量召回，交叉编码器精细筛选，二者搭配是 RAG 落地标配。

---

第四部分：质量保障

检索链路搭好了，下一个问题是：如何保证生成质量？这一部分聚焦幻觉处理和效果优化。

9. RAG 的幻觉怎么处理

幻觉是 RAG 项目最大的工程挑战，它本质上是检索召回和生成忠实度的级联问题——检索对了，生成却歪了。

幻觉的两种类型

类型	定义	举例
内在幻觉	检索结果里有正确信息，但 LLM 生成的内容与检索结果矛盾	检索说"准确率 91%"，LLM 说"准确率 95%"
外在幻觉	LLM 生成了检索结果里根本没有的内容	检索只提到了 A，LLM 自己编了 B

六种处理策略

策略	做什么	关键要点
1. Prompt 约束	在 Prompt 里明确要求"只能基于检索结果回答，检索结果没有的信息不要编造"	最基础的手段，但单独用不够，必须叠加其他策略
2. 输出自校验	LLM 生成回答后，再用一次 LLM 检查：回答的每一条是否都能在检索结果中找到依据，找不到的标注为"未验证"	能自动发现大部分编造内容，实现闭环校验
3. 引用标注	要求 LLM 在回答时标注每条信息的来源 chunk	方便人工核查，增强可信度，也是对齐生成与检索的显式约束
4. 温度调低	temperature 设 0.1–0.3，降低 LLM 的随机性	减少"自由发挥"的空间，显著降低编造倾向
5. 检索-生成对齐	生成回答后，把回答和检索结果做相似度对比，如果回答中有大段内容和所有检索结果都不相关，大概率是幻觉	用向量相似度做自动化度量，不依赖 LLM 自检
6. 兜底回答	当检索结果的相似度都低于阈值时，直接回答"未找到相关信息"	阻止 LLM 在没有依据时硬编，保护用户信任

输出自校验 Prompt 示例：

VERIFICATION_PROMPT = """
请检查以下回答是否每一条都能在参考资料中找到依据。
对于每条声明，标注：✅ 有依据 / ❌ 无依据 / ⚠️ 部分依据

回答：{answer}
参考资料：{context}
"""

工程开发的核心在于，如何结合不同的处理策略，以最大程度降低幻觉，提高召回率和准确率。

10. 检索效果不好怎么优化？

如何优化检索效果——从链路的每一步找问题，而不是盲目调参。

链路排查清单

处理阶段	需要检查的关键点
文档处理阶段	PDF 表格提取准确率够不够？图片里的文字有没有做 OCR？不同格式（PDF/Word/Markdown）分别做了什么适配？
Chunk 阶段	chunk_size 合不合理？有没有针对不同文档类型调参？overlap 设的多少？
检索阶段	纯向量还是混合检索？Top-K 设多少？有没有加 Rerank？
生成阶段	Prompt 怎么约束的？幻觉怎么处理的？

五种高级优化策略

优化策略	做什么	典型做法/示例
① Query 改写	用户问题表述不清或太短时，先用 LLM 改写成更适合检索的 query	原始：怎么调优？ 改写后：RAG 系统中向量检索准确率低，有哪些优化方法？
② 多路召回	同一问题用多种方式并行检索，合并结果	原问题检索 + 改写问题检索 + 关键词检索 + 拆分子问题检索
③ Parent-Child 检索	检索用小 chunk（精确匹配），返回用大 chunk（保留上下文）	小 chunk 存向量索引，关联父 chunk；检索命中后返回父 chunk 的完整内容
④ 上下文窗口扩展	检索到一个 chunk 后，把它前后的 chunk 也带上	命中 chunk 后自动补充前一个和后一个 chunk，保证逻辑连贯
⑤ 追问确认	如果问题太模糊，Agent 可以先追问用户澄清需求再检索	适合 Agentic RAG 场景，避免在信息不足时硬检索

---

第五部分：架构演进与工程落地

单机 RAG 跑通后，面临的下一个问题是如何扩展到生产环境。这一部分从架构演进、性能优化、成本控制到系统设计，覆盖工程化的关键决策。

11. Agentic RAG 是什么？和普通 RAG 有什么区别？

普通 RAG 的局限

普通 RAG 是固定流程：用户问 → 检索一次 → 生成回答。如果第一次检索结果不好，它不会自己纠正，直接硬生成。就像一个不会反思的人，说错就错到底。

Agentic RAG：让 RAG 自己决定怎么检索

Agentic RAG 把 Agent 的规划能力引入 RAG——LLM 自己判断：需要检索哪些数据源？检索结果够不够？不够就换个角度再检索。

对比维度	普通 RAG	Agentic RAG
检索次数	固定 1 次	动态，LLM 自主决定
检索策略	固定 pipeline	LLM 自主选择与调整
结果不满意时	直接生成（可能出错）	换策略重新检索
复杂问题	容易答偏	可拆解子问题分步检索
Token 消耗	低	高（多次推理+规划）

Agentic RAG 的工作流程

用户问题
   ↓
Agent 规划：这个问题需要检索什么？
   ↓
第一次检索 → 结果不够？
   ↓ (不够)
Agent 判断：换个 query 再检索
   ↓
第二次检索 → 结果够了？
   ↓ (够了)
Agent 判断：够了，生成回答

适用场景判断

Agentic RAG 适合复杂知识问答场景（法律、医疗、金融），简单问答用普通 RAG 就够了。

延伸：还有一类问题普通 RAG 和 Agentic RAG 都吃力——实体之间的复杂关联、多跳推理、全局关系归纳。这种场景要把检索从向量切到知识图谱。

12. RAG 系统的端到端延迟怎么优化？

优化链路：

• vLLM 部署推理服务：减少 LLM 推理延迟
• KV Cache 复用：相似问题不重复计算
• 流式输出：用户不用等全部生成完
• Prompt 压缩：减少 Token 数降低延迟
• HNSW 索引优化：向量检索延迟压到 50ms 以下

13. 文档更新了，向量索引怎么更新？

三种策略：

1. 全量重建：简单但慢，适合日级更新
2. 增量更新：只重新 embed 变更的文档，适合实时更新
3. 双写：新文档同时写旧索引和新索引，切换时零停机

14. RAG 的 Token 成本怎么控制？

• Prompt 压缩：裁剪检索结果中的冗余内容
• 上下文窗口管理：只保留当前问题相关的历史
• 模型路由：简单问题用小模型，复杂问题才用大模型
• 缓存：相同或相似问题的检索结果缓存复用

15. 设计一个面向 10 万用户的 RAG 知识库系统

从五个维度展开：

层级	设计要点
数据层	文档解析→Chunk→Embedding→向量库 + ES 双写
检索层	混合检索 + Rerank，Top-20 检索 + Top-5 精排
生成层	vLLM 部署 + Prompt 模板 + 幻觉约束
工程层	Redis 缓存热点查询、异步处理文档更新、监控检索准确率和幻觉率
安全层	文档权限隔离、Prompt Injection 防御、敏感信息过滤

---

附录：常见问题速查

Q：RAG 是什么？为什么需要 RAG？

RAG（检索增强生成）在大模型生成回答前，先从外部知识库检索相关信息塞进 Prompt，让模型基于事实回答。主要解决大模型三大缺陷：知识截止、私有数据无法触达、容易幻觉。

Q：RAG 的完整链路是怎么样的？

整体分两阶段：离线构建（文档清洗→Chunk 分块→Embedding 向量化→存入向量库）和在线问答（Query 向量化→相似度检索→Rerank 重排→拼接 Prompt→LLM 生成）。RAG 不是替代 LLM，是给 LLM 补充外部知识。

Q：向量检索的原理是什么？

把文本通过 Embedding 模型转为高维向量，语义相近的文本向量距离近。检索就是找离问题向量最近的文档向量。和关键词检索的本质区别：向量检索靠语义，关键词检索靠字面匹配。

Q：Embedding 模型怎么选？

中文场景首选 bge-large-zh-v1.5（1024 维，开源本地部署），多语言场景用 bge-m3。维度不是越高越好——维度高表达能力强，但存储和检索成本也更高。

Q：向量数据库怎么选？

FAISS 是嵌入式库，适合原型验证（百万级以下）；Milvus 是独立分布式数据库，适合大规模生产（亿级）；Qdrant 轻量级单节点，适合中小规模生产。选型关键看规模、持久化和运维成本。

Q：Chunk 怎么切？切大了切小了各有什么问题？

切大了信息稀疏，无关内容淹没关键信息；切小了上下文丢失，信息缺失倒逼模型编造。三种主流方式：固定长度（简单）、递归切分（按文章结构）、语义切分（按语义断点，效果最好）。Markdown 按标题切，PDF 先解析再切，代码按函数/类切，FAQ 整体不拆。

Q：纯向量检索有什么问题？为什么要用混合检索？

纯向量检索在精确匹配（如 RFC 编号）、专业术语（如 HPA）、专有名词上召回差——向量擅长"懂意思"但不擅长"找文字"。混合检索同时跑向量检索（语义）+ 关键词检索 BM25（精准文字），用 RRF 合并两路结果取长补短，是生产环境主流做法。

Q：混合检索权重应该怎么调？

两种做法：手动调权重（如向量 0.7 + BM25 0.3）在验证集试比例；或用 RRF 排名融合不设权重。生产环境推荐 RRF，因为不同 query 的最佳权重差异大，固定权重不一定好。

Q：Rerank 是什么？为什么检索之后还要重排序？

检索用 Bi-Encoder（双塔）快但粗，问句和文档分开编码，只能算大概相关；Rerank 用 Cross-Encoder（交叉编码器）把问题和文档拼在一起精算相关性，把真正相关的排到前面。先混合检索捞 Top-20，再 Rerank 精排取 Top-5，是 RAG 落地标配。

Q：Top-K 设多少？设大了设小了各有什么问题？

设小了（K=3）可能漏掉相关文档；设大了（K=20）无关信息干扰 LLM，增加幻觉风险和 Token 消耗。通常 K=5-10 是平衡点，加 Rerank 后先 K=20 粗筛再精排取 Top-5。

Q：RAG 的幻觉怎么处理？

幻觉分内在（有依据但生成矛盾）和外在（完全编造）。六种策略组合使用：Prompt 约束、输出自校验、引用标注、温度调低、检索-生成对齐、兜底回答。多策略叠加比单用一种效果好得多。

Q：检索效果不好怎么优化？

核心原则是从链路每一步排查，不盲目调参。五种高级策略：Query 改写（模糊问题改写为具体 query）、多路召回（多角度并行检索）、Parent-Child 检索（小 chunk 检索大 chunk 返回）、上下文窗口扩展（命中 chunk 前后也带上）、追问确认（问题太模糊时先澄清）。

Q：Agentic RAG 是什么？和普通 RAG 有什么区别？

普通 RAG 固定一次检索→生成，结果不好也不会纠正。Agentic RAG 引入 Agent 规划能力，LLM 自主决定检索次数和策略，结果不够就换个角度再检索。适合复杂知识问答，代价是 Token 消耗更高。

Q：RAG 系统的端到端延迟怎么优化？

五条链路：vLLM 部署加速 LLM 推理、KV Cache 复用减少重复计算、流式输出改善用户体验、Prompt 压缩减少 Token 数、HNSW 索引优化将向量检索压到 50ms 以下。

Q：文档更新了，向量索引怎么更新？

三种策略：全量重建（简单但慢，日级更新）、增量更新（只重新 embed 变更文档，实时更新）、双写（新文档同时写旧索引和新索引，切换零停机）。

Q：RAG 的 Token 成本怎么控制？

四招：Prompt 压缩裁剪冗余、上下文窗口管理只保留相关历史、模型路由（简单问题用小模型）、缓存复用相同/相似问题的检索结果。

Q：设计一个面向 10 万用户的 RAG 知识库系统怎么设计？

五层架构：数据层（文档解析→向量库+ES 双写）、检索层（混合检索+Rerank）、生成层（vLLM+Prompt 模板+幻觉约束）、工程层（Redis 缓存+异步更新+监控）、安全层（权限隔离+Prompt Injection 防御+敏感信息过滤）。

Q：RAG 和微调怎么选？

RAG 适合知识频繁更新、需要可溯源的场景，微调适合固化领域能力或改变输出风格。多数应用先用 RAG 验证，确有必要再考虑微调，两者也可以结合使用——微调让模型更懂领域表达方式，RAG 补充最新知识。

参考来源

• https://notes.kamacoder.com/interview/llm/rag_interview.html#写在最后

相关阅读

• Knowledge/AI/大模型-基础
• Milvus 向量数据库
• Knowledge/AI/大模型-知识扩展